Extensible template for asset token

ABSTRACT

A computer system comprises a logic system, and, operatively coupled to the logic system, a computer-memory system holding instructions that, when executed by the logic system, cause the computer system to: receive a token-behavior selection corresponding to a real-world asset to be tracked on a virtual ledger, the token behavior selection identifying a client-defined combination of behaviors; construct a template for registration of a token class on the virtual ledger according to the provider-defined architecture of the virtual ledger, wherein each new token instantiated from the token class exhibits the client-defined combination of behaviors as determined by the token-behavior selection; and provide access to the template to a client computer device.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationSer. No. 62/843,513, filed May 5, 2019, the entirety of which is herebyincorporated herein by reference for all purposes.

BACKGROUND

Virtual ledgers based on blockchain architecture can be used to trackthe creation, exchange, and redemption of certain real-world assets,such as currency. This approach enables robust auditing of assettransactions due to the practical immutability of data stored on ablockchain. Currency is only one of various assets that may be desirableto track on a virtual ledger. Other types of assets may differ fromcurrency with respect to one or more behaviors that govern assetcreation, exchange, and/or redemption. Moreover, different blockchainarchitectures may differ with respect to policies and protocols, andfurther with respect to the tools used to program asset behaviors.

SUMMARY

One aspect of this disclosure is directed to a computer-implementedmethod comprising receiving a token-behavior selection corresponding toa real-world asset to be tracked on a blockchain ledger, thetoken-behavior selection identifying a client-defined combination ofbehaviors. The method further comprises receiving token-behavior codeprogrammatically defining at least one component behavior of theclient-defined combination of behaviors. The method further comprisesconstructing a template for registration of a token class on theblockchain ledger according to a provider-defined architecture of theblockchain ledger, wherein each new token instantiated from the tokenclass exhibits the client-defined combination of behaviors as determinedby the token-behavior selection. The method further comprises adding thetoken class to the blockchain ledger.

Another aspect of this disclosure is directed to a computer systemcomprising a logic system, and, operatively coupled to the logic system,a computer-memory system holding instructions that, when executed by thelogic system, cause the computer system to: receive a token-behaviorselection corresponding to a real-world asset to be tracked on a virtualledger, the token behavior selection identifying a client-definedcombination of behaviors; construct a template for registration of atoken class on the virtual ledger according to a provider-definedarchitecture of the virtual ledger, wherein each new token instantiatedfrom the token class exhibits the client-defined combination ofbehaviors as determined by the token-behavior selection; and provideaccess to the template to a client computer device.

Another aspect of this disclosure is directed to a computer-implementedmethod comprising receiving a token-behavior selection corresponding toa real-world asset to be tracked on a virtual ledger, the token-behaviorselection identifying a client-defined combination of behaviors. Themethod further comprises constructing a template for registration of atoken class on the virtual ledger according to a provider-definedarchitecture of the virtual ledger, wherein each new token instantiatedfrom the token class exhibits the client-defined combination ofbehaviors as determined by the token-behavior selection. The methodfurther comprises adding the token class to the virtual ledger,receiving a token-management request relating to at least one tokeninstantiated from the token class, reformulating the token-managementrequest according to the provider-defined architecture, and submittingthe reformulated token-management request to a network hosting thevirtual ledger.

This Summary is provided to introduce in simplified form a selection ofconcepts that are further described in the Detailed Description. ThisSummary is not intended to identify key features or essential featuresof the claimed subject matter, nor is it intended to be used to limitthe scope of the claimed subject matter. The claimed subject matter isnot limited to implementations that solve any or all disadvantages notedin any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows aspects of an example virtual ledger in the form of ablockchain ledger residing on a peer-to-peer network.

FIG. 2 shows additional aspects of an example virtual ledger.

FIG. 3 shows aspects of an example computer system configured to enablea real-world asset to be represented and tracked as a token on a virtualledger.

FIG. 4A shows aspects of an example client user interface.

FIG. 4B shows aspects of an example marketplace user interface.

FIGS. 5 through 8 show aspects of example computer-implemented methodsto enable a real-world asset to be represented and tracked as a digitaltoken on a virtual ledger.

FIG. 9 shows examples of several real-world assets that may berepresented as tokens on a virtual ledger.

FIG. 10 shows aspects of an example computer system.

DETAILED DESCRIPTION

This disclosure is directed to a computer system and related networkservice to enable a real-world asset to he represented and tracked as atoken on a blockchain or other form of virtual ledger. A token is astrongly typed, digital data structure that derives from a token classappropriate for the type of asset to be tracked. In this approach, thetoken class from which each token is instantiated is formulatedautomatically based on an extensible token-class template constructedaccording to features identified by the client intending to deploy thevirtual ledger.

As noted above, various assets that can be tracked on a virtual (e.g.,blockchain) ledger may differ with respect to the behaviors that governasset creation, exchange, and/or redemption. In general, a virtualledger where each unit of an asset is represented by some form ofdigital token is programmed to endow that token with a set of behaviorsappropriate for the asset it represents. By way of example, ‘fungible’behavior enables an asset to be exchanged with other assets of the sameclass. Every unit of a given denomination of currency (e.g., a dollar)is fungible, because it has the same value as every other unit of thesame denomination. A property title, by contrast, is ‘non-fungible’because its value depends on the size, location, and other aspects ofthe specified property. For each asset represented as a token, theappropriate fungible or non-fungible behavior is programmed into thattoken's class in the virtual ledger that tracks the asset.

Naturally, a real-world asset may be characterized by numerous otherbehaviors besides fungibility. An asset may be ‘transferable’ or‘non-transferable’, ‘expirable’ or ‘non-expirable’, ‘mintable’,‘burnable’, and so on. In general, all of the behaviors of an assettracked on a virtual ledger should be programmed into that asset's tokenclass. Adding to this complexity is a lack of standardization among thepolicies, protocols and programming languages used in the variousblockchain architectures available today. As a result, a clientintending to deploy a virtual ledger to track an asset of interest mayhave to program the behaviors of each token class separately, for everyblockchain architecture on which a virtual ledger is to be deployed.

These issues, among others, are addressed by a computer system and/ornetwork service that enables the client to define the combination ofbehaviors of the asset of interest and the provider-defined architectureof the virtual ledger. The computer system automatically constructs areusable template for addition of a new token class to the virtualledger. The client may access the template in order to deploy thevirtual ledger, using, in some cases, a deployment package,application-programming interface (API) and/or software-development kit(SDK) automatically provided via the network service and customizedaccording to the indicated asset behaviors and virtual-ledgerarchitecture.

In this disclosure, an ‘asset’ is a thing of value that can be owned byor otherwise associated with a person or group of people; the term‘owner’ refers to the party to which an asset is associated, whereas‘client’ refers to any party that deploys and/or maintains a virtualledger for the purpose of tracking an asset. A client may be a person, acompany, an organization, or a government, as examples.

An asset can be created, redeemed, and, in some cases, exchanged betweenowners. Generally speaking, a ledger may be used to track these andother asset transactions. In the implementations disclosed herein, assettransactions are tracked on a virtual ledger—i.e., a strongly typed,digital data structure stored in a computer-memory system. By extendingappropriate read and write access to the data structure, the varioustransactions of any asset represented on the virtual ledger may berecorded and verified.

Some virtual ledgers may be hosted on a centralized computer-memorysystem maintained by an authority. Centralized hosting exposes the dataon a virtual ledger to risk of loss or corruption due to human error,malicious tampering, computer failure, and other causes. In view ofthese issues, a virtual ledger may be hosted on a decentralizedcomputer-memory system of a network of substantially independentcomputer devices. A virtual ledger hosted in this manner may take theform of a blockchain residing on a peer-to-peer network, as shown inFIG. 1.

Blockchain 102 of FIG. 1 includes a plurality of blocks 104 of digitaldata. Each block includes content data 106, a timestamp 108, and acryptographic digital signature 110, providing source-authentication ofthe content data. The timestamp may be supplied by adistributed-computing service executing on peer-to-peer network 112. Insome examples, the timestamp may be encrypted. Each block also includes,with the exception of genesis block 104A, a cryptographic hash 114 ofthe content data of a previously written, antecedent block. The hashlinks each block to its antecedent, defining the blockchain structure.

FIG. 1 shows a plurality of nodes 116 of peer-to-peer network 112.Embodied as a computer device with processing functionality, any node isable to verify the provenance of a given block 104 by determiningwhether it contains a valid hash of the content data from its antecedentblock. The verification can be iterated all the way back to the genesisblock 104A, if desired. This feature makes the content data of theblockchain effectively immutable, in the sense that it cannot be alteredwithout the approval of a consensus of nodes 116. As describedhereinafter, such nodes may include computer devices operated by theclient that maintains the virtual ledger and by the various owners ofthe asset being tracked on the virtual ledger. On a ‘public’ blockchain,blocks can be accessed and/or added by any computer device capable ofjoining peer-to-peer network 112. On a ‘private’ or ‘permissioned’blockchain, the permissions extended to each node are determined by acentral authority, such as the client.

Continuing in FIG. 1, virtual ledger 118 may be distributed within thecontent data 106 of any, some, or all of the blocks 104 of blockchain102. In this manner, the virtual ledger is shared among the variousnodes 116 of peer-to-peer network 112. FIG. 2 provides anotherrepresentation of virtual ledger 118 implemented to track the exchangeof an asset. Each asset of a particular kind is represented on thevirtual ledger by a token 202 of a corresponding token class 204. Eachtoken is an instance of its token class and is instantiated from hattoken class by system software 206 deployed on the peer-to-peer networkon which the virtual ledger resides.

Token class 204 defines the properties and behaviors of each token 202instantiated from that class. A ‘property’ may refer to data associatedwith the token. For example, the ‘owner’ property of a token may be aparameter value that represents the current owner of the asset that thetoken represents. By contrast, a ‘behavior’ may refer to a functionalaspect analogous to the asset behaviors referenced above (e.g.,fungible, transferable, and so on) and embodied as executable code orscript provided within the token class. The token class itself isregistered on virtual ledger 118 before any token of that class isinstantiated. As described further below, registration of the tokenclass may be achieved via a deployment package that executes on a clientcomputer device with access to peer-to-peer network 112.

FIG. 3 shows aspects of an example computer system 300 configured toenable a real-world asset to be represented and tracked as a digitaltoken on a virtual ledger. The computer system includes one or snoreclient computer devices 302 operated by a client with interest indeploying a virtual ledger for tracking an asset. The client computerdevices may be linked by a client network 304 such as a local-areanetwork (LAN) or a virtual private network (VPN). The computer systemalso includes one or more owner computer devices 306. In someimplementations, any, some, or all of the client and owner computerdevices may also be linked via a wide-area network (WAN), such as theInternet. In some implementations, the client and/or owner computerdevices may be instances of computing system 1000 of FIG. 10, which isdescribed hereinafter.

Continuing in. FIG. 3, client computer devices 302 and owner computerdevices 306 of computer system 300 are further linked by an additionalnetwork configured to support a virtual ledger. In the illustratedexample, this additional network takes the form of peer-to-peer network112, which is implemented on the client and owner computer devices(nodes 116 of the peer-to-peer network) according to the blockchainarchitecture defined by blockchain provider 308.

FIG. 3 shows blockchain 102 residing on the peer-to-peer network.Peer-to-peer network 112 comprises the combined computer-memory systemsof its various nodes 116—viz., the linked client and owner computerdevices; blockchain data including virtual ledger 118 may be storedredundantly on any, some, or all of the nodes. Accordingly, the nodes ofthe peer-to-peer network, on which the blockchain resides, may also bereferred to as nodes of the blockchain.

As noted above, various blockchain providers may support an architecturefor implementing a client's virtual ledger on a peer-to-peer network.However, the client still may face challenges in deployment of thevirtual ledger. In particular, the behavior of each token on the virtualledger should mirror the real-world behavior of the asset that the tokenrepresents. As every behavior that characterizes a token derives fromits token class, such behavior should be programmed into that tokenclass. However, token-behavior programming is not standard across thevarious provider-defined blockchain architectures, because differentarchitectures use different programming languages. Accordingly, theprocedure for registering a given token class may differ for the variousblockchain architectures, thereby requiring a different deploymentpackage for each blockchain architecture and token class. Furthermore,the different blockchain architectures may operate on peer-to-peernetworks that enforce different policies and use different protocols.Such differences may necessitate customized token-management softwareand owner software—which, in turn, may require a customizedsoftware-development kit (SDK) to support development of appropriateowner software by the client.

To address the above issues and to secure still other advantages,computer system 300 also includes a server system 310 comprising anetwork interface 311 and a plurality of service modules. The networkinterface comprises network hardware that communicatively couples eachof the service modules to one or more of the client computer devices302, via a WAN. In the example shown in FIG. 3, the service modules ofserver system 310 include a token-composability module 312, amarketplace module 314, a deployment module 316, and a support module318.

Token-composability module 312 is configured to receive input data froma client computer device 302 and to construct a token-class templatebased on the input data. The input data includes a token-behaviorselection corresponding to a real-world asset to be tracked on a virtualledger. The token-behavior selection determines the set of behaviorsrequired of each new token of the token class to be registered on thevirtual ledger. By supporting registration and instantiation of thetoken class, in addition to various transactions of the instantiatedtokens, the virtual ledger is adapted to track real-world assetsrepresented by the instantiated tokens. The input data provided totoken-composability module 312 may also include, inter alia, avirtual-ledger architecture selection that identifies theprovider-defined architecture of the virtual ledger. Using this inputdata, the token-composability module constructs a token-class templatefor registration of the token class on the virtual ledger according tothe provider-defined architecture o he virtual ledger. In this manner,each new token of the token class is guaranteed to correctly exhibit theindicated set of behaviors upon deployment on the virtual ledger. Thetoken-composability module is further configured to provide access tothe template to one or more client computer devices 302.

FIG. 4A shows aspects of an example client user interface (UI) 402configured for presentation on a client computer device 302. Shown insimplified form in FIG. 4A, the client UI includes a token-behaviorinput area 404, a text-expression dialog 406, a metadata-addition button408, and a metadata-value dialog 410. The client UI also includes avirtual-ledger architecture identification area 412, a request dialog414, and a response dialog 416. The illustrated features of client UI402 will be referenced in the context of the methods illustrated inFIGS. 5 through 8 and described hereinafter.

Returning now to FIG. 3, marketplace module 314 is configured to providea network service whereby a template constructed by token-composabilitymodule 312, based on a client's indicated combination of token behaviorsand virtual-ledger architecture, may be offered to other potentialclients for sale or license.

FIG. 4B shows aspects of an example marketplace UI 418 configured forpresentation to a client on a client computer device 302. Shown insimplified form in FIG. 48, the marketplace UI includes atemplate-description window 420. The illustrated features of client UI402 will be referenced in the context of the method illustrated in FIG.8 and described hereinafter.

Returning again to FIG. 3, deployment module 316 is configured to add anew token class to a virtual ledger based on a template constructed bytoken-composability module 312. To this end, the deployment modulecreates a customized deployment package 320 that executes on the virtualledger. In some examples, the deployment module may be furtherconfigured to construct and provide client access to anapplication-programming interface (API) 322 configured to expose one ormore behaviors and/or control functions of each new token of the tokenclass deployed on the virtual ledger. The API allows any tokenrepresenting an asset to be operated on (e.g., transferred, divided,expired, and so on) in an architecture-agnostic manner.

Via API 322, a client may create new token instances, view tokenbalances, transfer tokens, and/or call control functions for the tokenson a virtual ledger. In short, the client may use the API to developcomplex contracts without having familiar with the specific policies,protocols, and/or programming languages of any particular blockchainarchitecture. Token properties may be queried and stored in a registryvia the API.

API 322 may take the form of a representational state-transfer (REST)API in some examples. Using this type of API, the client need not beconcerned with any of the various ‘smart-contract’ details associatedwith token management. Instead, deployment module 316 may build aREST-addressable resource for each token class that the client creates,which exposes all of the control functions of that class. The REST APIdefinition may also define a request payload, which specifies functionarguments in an intuitive and generic way. This feature may enables aclient to develop owner applications that interact with tokens, evenwithout knowing how to program in the language of the provider-definedblockchain architecture. In some examples, a token template deployed toany type of blockchain may be interacted with using the same API, makingit possible to develop owner applications (vide infra) that areinter-operable on plural blockchains.

As noted above, a client may instantiate the one or more token classesregistered on a blockchain or other type of virtual ledger, associatingthe token instances to one or more owners to represent assets held bythe owners. In some examples, a client may enable an asset owner todirectly execute transactions involving his or her owned assets—e.g., toexchange or redeem an asset. To this end, the client may provide ownersoftware—such as a stand-alone owner application 323—to be executed orotherwise accessed from an owner computer device 306. Alternatively, orin addition, the client may provide an owner web app to be accessed bythe owner over the Internet. To facilitate the client's development ofsuch software, deployment module 316 may be further configured toconstruct and provide client access to a software-development kit (SDK)324 configured to facilitate access to one or more behaviors and/orcontrol functions of each new token of the token class on the virtualledger. The SDK may be customized for the appropriate token behaviorsand further customized, based on provider-defined policies andprotocols, for the virtual-ledger architecture.

Support module 318 is configured to facilitate client access to avirtual ledger after deployment. To this end, the support module mayserve as a conduit for various token-management requests and responsesexchanged between a client computer device 302 and peer-to-peer network112. Via the support module, interaction with token properties andbehaviors may surface in the form of relatively simple messagedefinitions agnostic to the specificalities of the virtual-ledgerarchitecture as defined by blockchain provider 308. Such messages mayrepresent token schema and state and may include one or more request/response message pairs, for example.

Each of the different virtual-ledger architectures may have differentprotocols and/or requirements with respect to token transactions. Forinstance, the procedures for submitting and signing transactions maydiffer. Moreover, the requirements governing uniqueness, retry logic,and finality of transactions may also differ. Accordingly, supportmodule 318 supports a submission pipeline that is architecture-agnostic.More particularly, the support module may be configured to receivevarious token-management requests relating to one or more new tokens ofa token class registered on the virtual ledger. As virtual ledgers ofdifferent architectures may differ with respect to messaging protocols,the support module may be configured to reformulate eachtoken-management request based on the provider-defined architecture ofthe virtual ledger and the policies and protocols therein. The supportmodule may be configured to submit each reformulated token-managementrequest to the peer-to-peer network 112 hosting the virtual ledger. Thesupport module may be likewise configured to receive various messages(e.g., response messages) from the host network and to reformulate themessages in an architecture-agnostic format, for consumption by clientcomputer devices 302.

FIG. 5 illustrates aspects of an example computer-implemented method 500to enable a real-world asset to be represented and tracked as a digitaltoken on a virtual ledger. In each of the methods herein, the virtualledger on which an asset is tracked may include a blockchain ledger;other types of virtual ledgers may also be used, however, alternativelyor in addition. In some examples, method 500 may be implemented on aserver system, such as server system 310 of FIG. 3. It will beunderstood, however, that not all implementations of the method requirethe detailed server architecture of server system 310 and may beimplemented on other types of computer systems.

At 502 of method 500, the server system receives a token-behaviorselection corresponding to a real-world asset to be tracked on a virtualledger. The token-behavior selection determines the set of behaviorsrequired of each new token of the token class to be registered on thevirtual ledger. By supporting registration and instantiation of thetoken class, in addition to various transactions of the instantiatedtokens, the virtual ledger is adapted to track real-world assetsrepresented by the instantiated tokens. Reflecting particular clientobjectives, the token-behavior selection may be composed by a client andreceived from a networked client computer device.

Supported behaviors of a token may be defined as capabilities orrestrictions. Behaviors may be common across all base token types, ormay only apply to a subset of base token types. Behaviors may havesupporting properties that become a part of the token schema anddefinition. Behaviors may be internal or external, depending on what thebehavior enables or restricts: an internal behavior may enable orrestrict properties of the token itself, whereas an external behaviormay enable or restrict the invocation of the behavior by an externalactor.

Each set of behaviors determined by a token-behavior selection maycomprise of one or more component behaviors. Some example componentbehaviors are defined below.

A ‘fungible’ token is interchangeable with every other token of the sametoken class. Tokens representing a particular currency denomination arefungible, for example. By contrast, a ‘non-fungible’ token is generallynot interchangeable with other tokens of the same class. Such behavioris appropriate for a token representing a property title, for example. A‘burnable’ token can be removed from a virtual ledger; a ‘non-burnable’token cannot be removed. A ‘delegable’ token may delegate one or morebehaviors of that token to a party that differs from the token owner.For example, a vote may be represented as a delegable token if the ownerof the underlying asset (i.e., the vote) delegates another owner to voteon his or her behalf. An ‘encumberable’ token may prevent certain nativebehaviors (e.g., burnable or transferable) from being invoked. An‘expirable’ token has time-bound validity on the virtual ledger on whichit is deployed. A ‘lockable’ token has the ability to freeze its currentstate. A token is ‘mintable’ if additional tokens of its token class canbe created. A ‘renewable’ token may be renew after expiration. A‘singleton’ token is limited to a supply of one on any virtual ledger. A‘subdividable’ token can be subdivided into plural tokens representingportions of an underlying asset, whereas a ‘whole’ token cannot besubdivided. A ‘transferable’ token can be transferred from its currentowner to another owner, whereas a ‘non-transferable’ token cannot betransferred. A token having ‘TransferFrom’ behavior can specify thesource owner in a transfer. A token having ‘RoleSupport’ behavior candefine roles within the token template class for additional behaviors.

Other component behaviors of a token may be derived from two or more ofthe elementary forms listed above. ‘Stretch Goal Hybrid’ tokens havecomponents of both fungible tokens and non-fungible tokens. Thisbehavior may be realized via a base token that owns the class of anothertoken. One such example is ‘non-fungible base with fungible segments’,e.g., a concert ticket, where the non-fungible parent token representsthe date and time of the concert, and where one or more fungible tokensegments represent tickets in one or more seating sections. Such ticketsare exchangeable within their section, but not across sections. Anotherexample is ‘fungible base with non-fungible segments’, e.g., a mortgagebacked security, where the fungible base can be split across manyinterchangeable owners, and where the non-fungible segments correspondto the individual mortgages that make up the security.

In some examples, the set of behaviors determined by a token-behaviorselection may be one of a plurality of predefined sets of behaviors. Inother words, certain sets of behaviors may be preselected for commonapplicability to plural asset types. In one example., the set ofbehaviors may include the combination of token-fungible behavior andinventory-control behavior. With the optional addition of RoleControlbehavior, the client acquires the ability to determine which owners mayexecute selected token transactions—e.g., to mint additional tokens ofthe same token class. In another example, the set of behaviors mayinclude the combination of token-fungible behavior and token-expirationbehavior. This option gives sets an expiration on the token'scirculation time, after which the token would no longer be tradable.Additional predefined sets of behaviors are also envisaged. Theseinclude ‘SupplyControl’ behavior, which groups together the abovemintable, burnable, and RoleSupport behaviors. ‘Financeable’ behaviorgroups together the above encumberable, whole, lockable, and rolesupport behaviors. ‘Custodial’ behavior groups together the abovedelegable and RoleSupport behaviors.

Some predefined sets of behaviors may be suited to relatively commonclient interests. A loyalty token, for instance, may comprise thefollowing behaviors: fungible (whole, transferable, expirable, burnable,mintable). In another example, a document token that supports afinancial security may comprise: non-fungible (whole, transferable,singleton, encumberable, burnable). Another relatively common setcorresponds to the behaviors of a hybrid token comprising a non-fungiblebase that can have fungible as well as non-fungible classes: hybrid withnon-fungible base (fungible classes (whole, transferable, expirable,burnable)). This example may be used to represent a theatre ticket, forinstance.

At 512 the server system receives a virtual-ledger architectureselection identifying a provider-defined architecture of the virtualledger. Example provider-defined architectures include the Ethereumarchitecture, the R3 Gorda architecture, the Hyperledger Fabricarchitecture, and the InterLedger architecture. Other blockchain andnon-blockchain virtual-ledger architectures are also envisaged.

In the methods herein, the manner by which the client provides thetoken-behavior and virtual-ledger architecture selections (among otherinput data) is not particularly limited. In some examples, theselections may be entered on a user interface (UI) of a networkapplication or web app component of token-composability module 312. Insome examples, the UI may offer a menu of options customized to theclient's commercial needs or other objectives. In some examples, the UImay present a command line interface that enables the client to enterthe token-behavior and virtual-ledger architecture selections as textexpressions (vide infra).

Returning briefly to FIG. 4A, client UI 402 includes a token-behaviorinput area 404 having a plurality of check boxes which refer tocomponent behaviors that may be included in a token-class definition.The client may select one or more of the component behaviors by checkingthe corresponding box or boxes. The token-behavior entry area alsoincludes a radio button that the client may select in order to causecheck boxes corresponding to various behavior groups (vide supra) toappear also on the client UI as selectable options. In some examples, asdescribed above, a complex token behavior may be expressible as asubclass, within which one or more component behaviors and/or nestedsubclasses are defined. Accordingly, the token-behavior entry area alsoincludes a button to trigger insertion of a new subclass in the tokenclass being formulated. Alternatively, or in addition to using thegraphical features noted above, a sophisticated client may enter a textexpression describing a combination of token behaviors directly intotext-expression dialog 406 of client UI 402. This feature is describedbelow, in the context of the method of FIG. 7. Client UI 402 alsoincludes a virtual-ledger architecture identification area 412, whichincludes a plurality of radio buttons that the client may use toidentify one of several supported virtual-ledger architectures. It willbe understood that the UIs illustrated herein are provided by way ofexample, and that other UI modalities are also envisaged.

Continuing now in FIG. 5, at 520 the server system constructs a templatefor the token class to be added to the virtual ledger. The template isconstructed based on the behaviors determined by the token-behaviorselection and according to the provider-defined architecture identifiedin the virtual-ledger architecture selection. The template isconstructed such that each new token of the token class exhibits theindicated set of behaviors. In some examples, a template so constructedmay be reusable for repeated addition of a token class to one or morevirtual ledgers.

In some examples, a template may be constructed modularly from codeportions or ‘snippets’ that are compatible with the provider-definedarchitecture of the virtual ledger. The server system may be configuredto combine the snippets and any other required components using syntaxand other protocols required by the architecture. From the point-of-viewof the virtual ledger, the result would be the same whether the tokenclass is created using the approach herein or authored manually by anexpert client.

To enable modular construction of a template based on code snippets, theserver system may include a library of verified code snippets definingthe component token behaviors from which the set of behaviors determinedby the token-behavior selection are constructed. Such snippets may bewritten in a language supported by the virtual-ledger architecture—e.g.,Solidity language for Ethereum architecture, ChainCode, Java, or Damillanguages for other blockchain architectures. Accordingly, ‘mintable’behavior may be associated with a Solidity snippet for deployment on anEthereum blockchain, and with a snippet composed in another language foreach of the other architectures. The various snippets may be combinedusing the class-construction framework of token-composability module312, in some examples.

At 528 the server system creates a token-deployment package based on thetemplate and on the provider-defined architecture of the virtual ledger.At 530 the server system constructs an API configured to expose one ormore behaviors and/or control functions of each new token of the tokenclass registered on the virtual ledger. The API may bearchitecture-agnostic and may provide, accordingly, a standardprogrammatic interface for interacting with deployed tokens on anysupported virtual ledger.

Depending on the type of token class constructed and on the differentbehaviors supported, the API may allow a client to fully manipulate thedeployed token instances. As a nonlimiting example, the API may providea standard interface to allow an asset owner to transfer one or moretoken assets to another party, using software provided by the client. Inother words, the API is one tool that the client may use to develop afront-end for translating owner intentions into actions supported by theregistered token class. As noted above, each API may bearchitecture-agnostic, in the sense that architecture-basedspecificalities are hidden from the application software calling the APIfunctions. Accordingly, the API may provide a uniform experience to theclient regardless of the blockchain architecture in use. In effect,neither the client nor the owners ultimately exchanging the asset needto know whether the virtual ledger resides on an Ethereum blockchain ora blockchain of some other architecture. Rather, the very same command(e.g., ‘transfer asset’) may be translated into desired actions informats compatible with virtual ledgers of different architectures.

At 532 the server system constructs an SDK configured to facilitateaccess to one or more behaviors and/or control functions of each newtoken of the token class on the virtual ledger. At 534 the server systemprovides client access to one or more of the token-deployment package,the API, and the SDK. In some examples, the server system may providenetwork access to these components. In some examples, the components aremade available to the client for download onto a client computer device.

At 536 the server system receives a token-class deployment instructionfrom a client computer device. Pursuant to receiving the token-classdeployment instruction, the server system at 538 adds the token class asspecified by the template to the virtual ledger. In implementationswhere the template is an extensible template that supports assignment ofclient metadata to one or more variable properties further illustratedin the method of FIG. 6), the token class, at 538, may be added withsuch metadata assigned to the one or more variable properties. Inexamples in which the server system has provided a token-deploymentpackage, the token class may be added to the virtual ledger by executionof the token-deployment package on the network hosting the virtualledger. In this example, the server system provides network access tothe constructed template via the client computer device that issues thedeployment instruction. In other examples, the server system may providedirect access to a constructed template—e.g., by offering the templatefor download onto a client computer device.

Generally speaking, the token-class deployment instruction received at536 may be one of a plurality of client instructions received by theserver system. In some implementations, certain non-standard and/ornon-generic policies or protocols may govern the exchange ofinstructions and other messages with a virtual ledger or supportingnetwork. Such policies or protocols may derive from the provider-definedarchitecture of the virtual ledger and may differ from one architectureto the next. Instead of requiring the client to be familiar with thepolicies and protocols of every virtual-ledger architecture supported,the server system may be configured to receive instructions and othermessages from a client computer device in an architecture-agnostic(i.e., standard or generic) format. Then, the server system mayreformulate each of the client instructions received according to thepolicies and protocols of the virtual ledger as determined by theprovider-defined architecture of the virtual-ledger. The server systemmay subsequently pass each of the reformulated instructions to thenetwork hosting the virtual ledger. Likewise, the server system mayreceive, in a non-standard or non-generic form, a plurality of messagesfrom the network hosting the virtual ledger. The server system mayreformulate the messages received into an architecture-agnostic format,and provide client access to each of the reformulated messages. In thismanner, the server system enables the client to submit instructions toany supported virtual ledger, and to exchange messages with anysupported virtual ledger, even without knowing the architecture-specificpolicies and protocols of the virtual ledger. This approach is furtherillustrated at 540, ff. in method 500.

At 540 the server system receives a token-management request relating toat least one new token instantiated from a token class registered on avirtual ledger. At 542 the server system reformulates thetoken-management request according to the provider-defined architecture,including relevant policies and protocols. At 544 the server systemsubmits the reformulated token-management request to the network hostingthe virtual ledger. At 546 the server system receives a token-managementresponse. At 548 the server system reformulates the token-managementresponse into an architecture-agnostic format based, again, on thepolicies and protocols of the virtual ledger as determined by thevirtual-ledger architecture. At 550 the server system provides clientaccess to the reformulated token-management response. Returning brieflyto FIG. 4A, client UI 402 includes a request dialog 414 that the clientmay use to enter an architecture-agnostic request to a deployed virtualledger. The client Ul also includes a response dialog 416 that theclient may use to view a response from the deployed virtual ledger,which is reformulated in architecture-agnostic format.

FIG. 6 shows aspects of another example computer-implemented method 600to enable a real-world asset to be represented and tracked as a digitaltoken on a virtual ledger. Method 600 is particularly directed tocustomizing otherwise predefined token classes based on metadataprovided by a client., In some examples, this method may be implementedon a server system, such as server system 310 of FIG. 3. It will beunderstood, however, that not all implementations of the method requirethe detailed server architecture of server system 310 and may beimplemented on other types of computer systems. It will be understoodalso that any process step of this or a subsequent method that has areference number coordinate to a process step of a previous method (612is coordinate to 512, for example) may inherit any feature of theprevious method step. Nevertheless, such inheritance is not strictlynecessary, as coordinately numbered process steps may differ in someexamples.

At 602 of method 600, the server system receives a token-behaviorselection that determines the set of behaviors required of each newtoken of a token class. In some examples, the indicated set of behaviorsmay be one of a plurality of predefined sets of behaviors. In otherwords, certain sets of behaviors may be preselected for commonapplicability to many asset types. At 612 the server system receives avirtual-ledger architecture selection identifying a provider-definedarchitecture of the virtual ledger.

At 614 the server system receives client metadata for assignment to avariable property of each new token of the token class. In someexamples, the metadata can be added to the token class withoutfundamentally changing the behavior of the tokens derived from thatclass. Non-limiting examples of such metadata include a name, serialnumber, reference property, SKU, or generic tag. By incorporating suchmetadata, the same template—e.g., for a fungible token withSupplyControl—can be modified by different clients to build out loyaltyprograms with different loyalty token names. Each resulting token wouldthen be customized to the client—e.g., Alpha Coffee loyalty token, BravoAirlines loyalty token, and so on. To achieve this effect, among others,the client may specify one or more customization options at the templatelevel by supplying metadata to be included in the corresponding tokenclass. Stated another way, the client is able to supply one or morekey-value mappings for each token instance to be created from the tokenclass.

In some examples, the variable property instantiated by the metadata mayprovide an initial customization applied in common to each new token ofthe token class. More particularly, the template may, in some examples,be configured such that the variable property of each new token of thetoken class is fixed upon instantiation of that token on a virtualledger. In other examples, the template may be configured such that thevariable property of each new token of the token class is adjustableafter that token is instantiated on the virtual ledger. This variantprovides an. opportunity for further differentiation among tokeninstances after deployment. In some examples, a dedicated‘CustomMetadata’ behavior may be encoded in a token template to indicatethat tokens derived from the template have queryable metadata.

Neither the significance nor the format of the variable property isparticularly limited. In some examples, the variable property mayinclude text. In some examples, the variable property may include anumeric value. In these and other examples, the variable property mayinclude a link to data which is external to a virtual ledger. Inimplementations in which the variable property includes a link to dataexternal to the virtual ledger, method 600 may further comprise, at 618,storing the data external to the virtual ledger on a network-accessibledata-storage system.

This feature provides an advantage in scenarios in which a significantvolume of data is to be associated with one or more token instances. Forexample., a token that represents an owner's right to consume a digitalmedia asset may be associated with the digital media asset itself—e.g.,an audio or video file, which may be very large. While such data may bestored directly within a token structure (i.e., redundantly, on everynode of a blockchain), doing so would consume resources and degrade theperformance of the blockchain. An effective alternative in thesescenarios is to store only a link to the data within the tokenstructure, and to store the actual data on a network-accessible serviceexternal to the blockchain.

Returning again to FIG. 4A, the client may specify the addition ofmetadata to a token class being formulated via client UI 402. Byselecting metadata addition button 408, the client may specify that avalue is to be assigned to an indicated variable property of the tokenclass. After the button is selected, the client may then enter thedesired property value in metadata-value dialog 410.

Continuing now in FIG. 6, at 620 the server system constructs a templatefor the token class to be added to the virtual ledger. Constructed basedon the behaviors defined by the token-behavior selection and accordingto the provider-defined architecture identified in the virtual-ledgerarchitecture selection, the template includes the client metadatareceived at 614 of method 600. In some examples, the template may bereusable for repeated addition of the token class to one or more virtualledgers. Following 620, method 600 may continue at 528 of method 500 ofFIG. 5, as all of the methods presented in this disclosure are usableboth separately and together.

FIG. 7 illustrates aspects of another example computer-implementedmethod 700 to enable a real-world asset to be represented and tracked asa digital token on a virtual ledger. Method 700 is particularly directedto extending token classes to support client-defined combinations oftoken behaviors, in some cases including previously undefined tokenbehaviors. In some examples, this method may be implemented on a serversystem, such as server system 310 of FIG. 3. It will be understood,however, that not all implementations of the method require the detailedserver architecture of server system 310 and may be implemented on othertypes of computer systems.

At 702 of method 700, the server system receives a token-behaviorselection that identifies the client-defined combination of behaviorsrequired of each new token of a token class. Such data may be receivedfrom a networked client computer device. In some examples, theclient-defined combination of behaviors may include at least onepredefined component behavior. However, the overall combination ofbehaviors may be particular to the client's needs and specificallyconstructed to specifically reflect the underlying behaviors of theasset to be tracked.

In one example, the server system, via any suitable application or webapp, may present a wizard that asks the client a series of questions.The questions and the sequence in which the questions are presented maybe configured to allow a client to define a token class having anyconfiguration supported by a compatible virtual ledger. Alternatively,the server system, again via any suitable application or web app, maypresent a user interface, such as client UI 402 of FIG. 4A, which allowsa client to select token properties and/or behaviors from a menu. Theuser interface may be configured to prevent selection of incompatibleproperties and/or behaviors (as further developed at 710 of thismethod). As another alternative, the server system may present a corm.and-line interface, also shown in FIG. 4A, that allows the client toenter directly a text expression that represents the client-definedcombination of behaviors.

In some implementations, a text expression representing a combination ofbehaviors may be formulated according to a standard vocabulary andgrammar recognized by token-composability module 312. The textexpression may symbolize a base-level behavior—e.g., τ_(F) for fungiblebehavior and τ_(N) for non-fungible behavior. The text expression mayalso symbolize hybrid token behavior. For instance, τ_(N)(τ_(F))symbolizes a non-fungible base with a fungible class; τ_(F)(τ_(N))symbolizes a fungible base with a non-fungible class.

Particular token behaviors may be symbolized by lower-case letters,optionally prepended by a NOT symbol (˜). By way of example, t maysymbolize transferrable behavior, while ˜t may symbolizenon-transferrable behavior; d may symbolize subdividable behavior, while˜d may symbolize whole behavior. Furthermore, s may symbolize singletonbehavior, m may symbolize mintable behavior, r may symbolize RoleSupportbehavior, b may symbolize burnable behavior, e may symbolize expirablebehavior, and g may symbolize delegable behavior.

A behavior group may be symbolized by an upper-case letter or unique setof letters with a corresponding behavior formula enclosed in curlybraces. For example, SupplyControl behavior may be symbolized SC {m, b,r}. This formulation is useful for representing more complexcombinations of token behaviors of common assets. The behaviorscharacterizing currency may be symbolized τ_(F) {SC}. The behaviorscharacterizing a vote may be symbolized τ_(N) {˜t, S}, where S refers tosuspendable behavior. In this approach, behaviors characterizing atheatre ticket may be symbolized τ_(N)(τ_(F)) {e, t}; behaviorscharacterizing a commodity may be symbolized τ_(F){˜d, g, SC}.

As yet another alternative, the server system may support an API thatallows first and/or third party front-ends to interact withtoken-composability module 312 (referring again to FIG. 3), so that anydesired front-facing user experience can be designed to take advantageof the back-end framework of the token-composability module. Variousdifferent front-end approaches can be designed to translate clientselections into corresponding text expressions. Like the wizard and UIalternatives, this approach allows the client to take advantage of thetoken-composability grammar (vide infra) without having to learn thegrammar.

Using any of the approaches described herein, the client can modify anexisting template by adding and/or removing selected behaviors. Theresulting modified template may be saved in the server system for laterreuse. If the client de res to use the newly composed template again, heor she may select the template from a history list. This feature enablesthe client to quickly move beyond predefined templates and createextended templates to match commercial, organizational, social, and/orgovernmental objectives.

At 704 the server system represents the client-defined combination ofbehaviors as a text expression according to a token-behavior grammar.Earlier in the description of method 700 it was noted that theclient-defined combination of token behaviors could be initiallyspecified as a text expression, as one of several alternatives that alsoinclude the use of a wizard, UI or API. In implementations in which theclient-defined combination is not initially specified as a textexpression, the client-defined combination may be reformulated as a textexpression, in order to take advantage of the powerful features of thetoken-composability grammar. Such features include the ability to verifythe self-consistency of client-defined combinations of behaviors (videinfra).

In these and other examples, a client-defined combination of behaviorsmay include at least one previously undefined component behavior. Inimplementations in which at least one previously undefined componentbehavior is included in a client-defined combination, method 700 mayfurther comprise, at 706, the optional step of receiving token-behaviorcode programmatically defining the at least one previously undefinedcomponent behavior. The method may further comprise, at 708, theoptional step of verifying the operability of the token-behavior code onthe indicated virtual ledger. In the scenario in which thetoken-behavior code executes without error, the token-behavior code maybe stored in token-composability module 312 as a snippet andincorporated into the token class defined by the template. In thescenario in which the token-behavior executes erroneously or does notexecute, execution of method 700 may be suspended.

At 710, irrespective of whether the client-defined combination includesa previously undefined component behavior, the server system may assessthe self-consistency of the client-defined combination of behaviors.Verification may take the form of a hard coded check including a seriesof tests to make sure that mutually incompatible properties and/orbehaviors are not specified concurrently for the same token class. Inother cases, configurable rules may be passed to the verifier. As asimplistic example, mintable may not be compatible with burnable. Beforeinstantiating a token class for a particular virtual ledger, theverifier may determine that if the expression combines mintable andburnable, then the token class will not be generated. Although in someexamples and scenarios, a given virtual-ledger architecture may notsupport a given combination of behaviors, such as mintable and burnable,a different virtual-ledger architecture may allow these same behaviorsto combined. Accordingly, in a scenario in which ten differentprovider-defined architectures are supported and each architecture cansupport different client-defined combinations of behaviors, therequirements may be set individually for each architecture.

In some examples, verification of the self-consistency of client-definedcombinations of behaviors may include application of certain grammarrules to combinations formulated as text expressions. Grammar rules maybe scoped to support particular limitations. For example, the followingbehaviors are incompatible or orthogonal: (whole or singleton) andsubdividable; (transferable or TransferFrom or delegable) andnon-transferable. Furthermore, burnable should be automatically turnedoff if there is supply left, and only if a token has ‘expired’ can it bere-activated through the ‘renew’ behavior. In the scenario in which aclient-defined combination of token behaviors is self-consistent, thatcombination may be added to the token class defined by the template. Inthe scenario in which a client-defined combination of token behaviors isnot self-consistent, execution of method 700 may be suspended.

At 712 the server system receives a virtual-ledger architectureselection identifying a provider-defined architecture of the virtualledger. At 720 the server system constructs a template for the tokenclass to be added to the virtual ledger. The template is constructedbased on the client-defined combination of behaviors determined by thetoken-behavior selection and according to the provider-definedarchitecture identified in the virtual-ledger architecture selection.The template is constructed such that each new token of the token classexhibits the indicated client-defined combination of behaviors. In someexamples the template constructed at 720 may be a derived template thatinherits one or more properties and/or behaviors of a preexistingtemplate; here, one or more properties and/or behaviors defined by thepreexisting template may be overridden by the client-defined combinationof behaviors as defined by the derived template. In some examples, thetemplate may be reusable for repeated addition of the token class to oneor more virtual ledgers. Following 720, method 700 may continue at 528of method 500 of FIG. 5, as all of the methods presented in thisdisclosure are usable both separately and together.

FIG. 8 illustrates aspects of another example computer-implementedmethod 800 to enable a real-world asset to be represented and tracked asa digital token on a virtual ledger. Method 800 is particularly directedto sharing and/or monetizing token classes supporting client-definedcombinations of behaviors, such token classes being valuable not only tothe authoring client but to other clients with similar asset-trackingneeds. In some examples, this method may be implemented on a serversystem, such as server system 310 of FIG. 3. It will be understood,however, that not all implementations of the method require the detailedserver architecture of server system 310 and may be implemented on othertypes of computer systems.

At 802 the server system receives a token-behavior selection from afirst client. The token-behavior selection determines the client-definedcombination of behaviors required of each new token of a token class tobe registered on the virtual ledger. In some examples, theclient-defined combination of behaviors may include at least onepredefined component behavior. However, the overall combination ofbehaviors may be particular to the first client's needs and specificallyconstructed to specifically reflect the underlying behaviors of theasset to be tracked. The specified combination of behaviors may also beapplicable to the needs of other clients—e.g., to track differentassets.

At 804 the server system represents the client-defined combination ofbehaviors as a text expression according to a token-behavior grammar. Inthese and other examples, the client-defined combination of behaviorsmay include at least one previously undefined component behavior. Inimplementations in which at least one previously undefined componentbehavior is included in the client-defined combination, method 800 mayfurther comprise, at 806, the optional step of receiving token-behaviorcode programmatically defining the at least one previously undefinedcomponent behavior. The method may further comprise, at 808, theoptional step of verifying the operability of the token-behavior code onthe specified virtual ledger. At 810, irrespective of whether theclient-defined combination includes a previously undefined componentbehavior, the server system may assess the self-consistency of theclient-defined combination of behaviors. At 812 the server systemreceives a virtual-ledger architecture selection from the first client.The virtual-ledger architecture selection identifies a provider-definedarchitecture of the virtual ledger.

At 820 the server system constructs a template for the token class to beadded to the virtual ledger. The template is constructed based on theclient-defined combination of behaviors determined by the token-behaviorselection and according to the provider-defined architecture identifiedin the virtual-ledger architecture selection. The template isconstructed such that each new token of the token class exhibits theindicated client-defined combination of behaviors. In some examples thetemplate constructed at 820 may be a derived template that inherits oneor more properties and/or behaviors of a preexisting template; here, oneor more behaviors defined by the preexisting template may be overriddenby the client-defined combination of behaviors as defined by the derivedtemplate. In some examples, the template may be reusable for repeatedaddition of the token class to one or more virtual ledgers.

A template constructed based on the specifications of the first clientmay be offered for sale or license to other interested clients. At 822,ff., of method 800, the server system facilitates this activity. At 822,the template prepared according to the specifications of the firstclient is copied to a marketplace service module of the server system,which is accessible to other potential clients. The marketplace servicemay be configured to recognize, predict, or receive as input, anindication of the asset-tracking needs of the potential clients that loginto the marketplace service. Via analysis of each potential clientsasset-tracking needs, the marketplace service may present to eachpotential client a customized menu of token-template options. At 824 ofmethod 800, the template prepared according to the specifications of thefirst client is included in the template options presented to a secondclient. Presentation of the template properties and/or behaviors to thesecond client may include a plain-language description of theclient-defined combination of token behaviors associated with thattemplate. Returning briefly to FIG. 4B, the plain-language descriptionmay appear in template-description window 420 of marketplace UI 418. lf,after examination of this template (i.e., of the description of theclient-defined combination of behaviors therein) the second clientindicates interest in the template, then the template is provided, at826 of FIG. 8, for sale or license to the second client.

Marketplace access to the template may be provided in this manner to aplurality of client computer devices operated by different clients. Thisservice may include a back end for transferring a purchased or licensedtemplate to buyer in exchange for compensation. In examples in which thetemplate is composed based on a combination of behaviors specified by afirst client and intended to be offered for sale or license to otherclients, any text expression formulated in token-behavior grammar may bemasked in the template. In more particular examples, such textexpressions may be encrypted. By virtue of encryption or other forms ofmasking, the first client may be assured that template does not reveal areusable text expression to potential competitors, consumers, orlicensees. Following 826, method 800 may continue at 528 of method 500of FIG. 5, as all of the methods presented in this disclosure are usableboth separately and together. In transitioning to method 500, it will beunderstood that e token-class deployment instruction and anytoken-management instructions are received from a client computer deviceoperated by a second client.

No aspect of the foregoing drawings or description should be construedin a limiting sense, as numerous extensions, variations, and omissionsare also envisaged. For instance, each of the methods illustrated inFIGS. 5 through 8 includes a step of receiving a virtual-ledgerarchitecture selection identifying a provider-defined architecture ofthe virtual ledger. In implementations supporting a singlevirtual-ledger architecture, however, this step may be omitted. In suchimplementations, any instruction to create a token template is aninherent selection of the single supported virtual-ledger architecture.It may also be omitted in the hypothetical scenario in which thepolicies, protocols, and/or programming languages of the variousvirtual-ledger architectures have become standardized,

Although this disclosure emphasizes blockchain implementations of avirtual ledger, other network-based approaches are also envisaged, Inone example, a network-accessible XML document comprising a series oftimestamped, user-authenticated sections may be used to support avirtual ledger for tracking a real-world asset. A cryptographicsignature in addition to other encrypted data—may be included in an XMLfile in any suitable encoding (e.g., a Base64 encoding using ASCIIcharacters).

FIG. 9 shows examples of several real-world assets that may be trackedusing the systems and methods disclosed herein. More particularly, thedrawing shows a unit 902 of currency, a theatre ticket 904, an airlineticket 906, an airline rewards point 908, a hotel rewards point 910, anda vote 912. As noted above, the unit of currency is fungible. The unitof currency is also freely transferrable from one owner to another. Eventhough the airline ticket and airline rewards point may be issued by thesame client, and, in some examples, tracked on the same virtual ledger,these assets have different behaviors. The airline ticket specifies aparticular flight number, passenger identity, flight date, and seatassignment, and is therefore both non-fungible and non-transferrable,whereas the airline rewards point is both fungible and transferrable.The vote may be fungible but non-transferrable, if issued by agovernment. A vote issued by a corporation may be generallynon-transferrable, but ‘delegable’ to another voter, in some scenarios.

The examples illustrated above should not be construed to limit theapplication space of the asset-tracking methods disclosed herein, assuch methods are applicable to wide range of client objectives. Oneexample relates to a loyalty program suitable for a major hotel chain.The hotel chain may have a robust loyalty program that leverages one ormore partner programs. In a scenario in which the hotel chain's loyaltytokens are to be redeemed, the hotel chain's customer, a token owner,may desire to purchase an airline ticket from an airline partner of thehotel chain. The customer, therefore, may log into the hotel chain'sloyalty platform to initiate a spend request. On the back end, the hotelchain's business logic converts the hotel chain's loyalty token, definedby token-composability module 312, to the airline's loyalty token andloads the customer's airline loyalty account accordingly. The customercan then purchase an airline ticket with airline loyalty points.

In a scenario in which loyalty tokens are to be exchanged betweenowners, a token owner may desire to trade one or more of the hotelchain's loyalty tokens for loyalty tokens of a partner of the hotelchain. This customer may then log into the hotel chain's loyalty programto visit a loyalty-token exchange platform, which reveals whetheranother token owner wishes to trade the specified tokens. If so, asuitably developed front-end system may facilitate the trade.

In a scenario related to the field of trade finance, a brokerage maysupport a finance platform using blockchain technology, focusing on pre-and post-shipment trade finance solutions. In a scenario related toletters of credit, a client may tokenize an actual financial instrument.Token-composability module 312 may offer a document token with specificproperties associated with a letter of credit, such as a document hashwith signatures required, etc. Additional application scenarios extendto the field of commodity financing, where two or more platforms need towork closely together to ensure that financing and commodity tradeshappen in a trusted manner. In a scenario related to encumbering assets,token-composability module 312 may be used to create a token class thatmakes the act of encumbering an asset a more automated process in thecommodity financing use cases. An encumbering token may be created andassigned on the plural networks, to be associated with the financing orcommodity to be traded.

The methods and processes described herein may be tied to a computingsystem of one or more computing devices. In particular, such methods andprocesses may be implemented as an computer-application program, anetwork-accessible computing service, an application-programminginterface (API), a library, or a combination of the above and/or othercompute resources.

FIG. 10 schematically shows a simplified representation of a computingsystem 1000 configured to provide any to all of the computefunctionality described herein. Computing system 1000 may take the formof one or more personal computers, workstations, network-accessibleserver computers, tablet computers, mobile communication devices (e.g.,smart phones), and/or other computing devices.

Computing system 1000 includes a logic subsystem 1002 and a storagesubsystem 1004. Computing system 1000 may optionally include a displaysubsystem 1006 input subsystem 1008, communication subsystem 1010,and/or other subsystems not shown in FIG. 10.

Logic subsystem 1002 includes one or more physical devices configured toexecute instructions. For example, the logic subsystem may be configuredto execute instructions that are part of one or more operating systems,applications, services, or other logical constructs. The logic subsystemmay include one or more hardware processors configured to executesoftware instructions. Additionally or alternatively, the logicsubsystem may include one or more hardware or firmware devicesconfigured to execute hardware or firmware instructions. Processors ofthe logic subsystem may be single-core or multi-core, and theinstructions executed thereon may be configured for sequential,parallel, and/or distributed processing. Individual components of thelogic subsystem optionally may be distributed among two or more separatedevices, which may be remotely located and/or configured for coordinatedprocessing. Aspects of the logic subsystem may be virtualized andexecuted by remotely-accessible, networked computing devices configuredin a cloud-computing configuration.

Storage subsystem 1004 includes one or more physical devices configuredto temporarily and/or permanently hold computer information such as dataand instructions executable by the logic subsystem. When the storagesubsystem includes two or more devices, the devices may be collocatedand/or remotely located. Storage subsystem 1004 may include volatile,nonvolatile, dynamic, static, read/write, read-only, random-access,sequential-access, location-addressable, file-addressable, and/orcontent-addressable devices. Storage subsystem 1004 may includeremovable and/or built-in devices. When the logic subsystem executesinstructions, the state of storage subsystem 1004 may betransformed—e.g., to hold different data.

Aspects of logic subsystem 1002 and storage subsystem 1004 may beintegrated together into one or more hardware-logic components. Suchhardware-logic components may include program- and application-specificintegrated circuits (PASIC ASICs), program- and application-specificstandard products (PSSP/ASSPs), system-on-a-chip (SOC), and complexprogrammable logic devices (CPLDs), for example.

The logic subsystem and the storage subsystem may cooperate toinstantiate one or more logic machines. As used herein, the term‘machine’ is used to collectively refer to the combination of hardware,firmware, software, instructions, and/or any other componentscooperating to provide computer functionality. In other words,‘machines’ are never abstract ideas and always have a tangible form. Amachine may be instantiated by a single computing device, or a machinemay include two or more sub-components instantiated by two or moredifferent computing devices. In some implementations a machine includesa local component (e.g., software application executed by a computerprocessor) cooperating with a remote component (e.g., cloud computingservice provided by a network of server computers). The software and/orother instructions that give a particular machine its functionality mayoptionally be saved as one or more unexecuted modules on one or moresuitable storage devices.

Machines may be implemented using any suitable combination ofstate-of-the-art and/or future machine learning (ML), artificialintelligence (Al), and/or natural language processing (NLP) techniques.Non-limiting examples of techniques that may be incorporated in animplementation of one or more machines include support vector machines,multi-layer neural networks, convolutional neural networks (e.g.,including spatial convolutional networks for processing images and/orvideos, temporal convolutional neural networks for processing audiosignals and/or natural language sentences, and/or any other suitableconvolutional neural networks configured to convolve and pool featuresacross one or more temporal and/or spatial dimensions), recurrent neuralnetworks (e.g., long short-term memory networks), associative memories(e.g., lookup tables, hash tables, Bloom Filters, Neural Turing Machineand/or Neural Random Access Memory), word embedding models (e.g., GloVeor Word2Vec), unsupervised spatial and/or clustering methods (e.g.,nearest neighbor algorithms, topological data analysis, and/or k-meansclustering), graphical models (e.g., (hidden) Markov models, Markovrandom fields, (hidden) conditional random fields, and/or Al knowledgebases), and/or natural language processing techniques (e.g.,tokenization, stemming, constituency and/or dependency parsing, and/orintent recognition, segmentable models, and/or super-segmentable models(e.g., hidden dynamic models)).

When display subsystem 1006 may be used to present a visualrepresentation of data held by storage subsystem 1004 This visualrepresentation may take the form of a graphical user interface (GUI).Display subsystem 1006 may include one or more display devices utilizingvirtually any type of technology. In some implementations, displaysubsystem may include one or more virtual-, augmented-, or mixed realitydisplays.

When included, input subsystem 1008 may comprise or interface with oneor more input devices. An input device may include a sensor device or auser input device. Examples of user input devices include a keyboard,mouse, or touch screen.

When included, communication subsystem 1010 may be configured tocommunicatively couple computing system 1000 with one or more othercomputing devices. Communication subsystem 1010 may include wired and/orwireless communication devices compatible with one or more differentcommunication protocols. The communication subsystem may be configuredfor communication via personal-, local- and/or wide-area networks.

This disclosure is presented by way of example and with reference to theattached drawing figures. Components, process steps, and other elementsthat may be substantially the same in one or more of the figures areidentified coordinately and are described with minimal repetition. Itwill be noted, however, that elements identified coordinately may alsodiffer to some degree. It will be further noted that the figures areschematic and generally not drawn to scale. Rather, the various drawingscales, aspect ratios, and numbers of components shown in the figuresmay be purposely distorted to make certain features or relationshipseasier to see.

One aspect of this disclosure is directed to a computer-implementedmethod comprising: receiving a token-behavior selection corresponding toa real-world asset to be tracked on a blockchain ledger, thetoken-behavior selection identifying a client-defined combination ofbehaviors; receiving token-behavior code programmatically defining atleast one component behavior of the client-defined combination ofbehaviors; constructing a template for registration of a token class onthe blockchain ledger according to a provider-defined architecture ofthe blockchain ledger, wherein each new token instantiated from thetoken class exhibits the client-defined combination of behaviors asdetermined by the token-behavior selection; and adding the token classto the blockchain ledger.

In some implementations, the method further comprises verifyingoperability of the token-behavior code on the blockchain ledger. In someimplementations, the method further comprises assessing self-consistencyof the client-defined combination of behaviors. In some implementations,the template is a derived template that inherits one or more propertiesof a preexisting template, wherein one or more behaviors defined by thepreexisting template are overridden by the client-defined combination ofbehaviors as defined by the derived template. In some implementations,the client-defined combination of behaviors includes at least onepredefined component behavior.

Another aspect of this disclosure is directed to a computer systemcomprising a logic system and, operatively coupled to the logic system,a computer-memory system holding instructions that, when executed by thelogic system, cause the computer system to: receive a token-behaviorselection corresponding to a real-world asset to be tracked on a virtualledger, the token behavior selection identifying a client-definedcombination of behaviors; construct a template for registration of atoken class on the virtual ledger according to a provider-definedarchitecture of the virtual ledger, wherein each new token instantiatedfrom the token class exhibits the client-defined combination ofbehaviors as determined by the token-behavior selection; and provideaccess to the template to a client computer device.

In some implementations, the virtual ledger includes a blockchainledger. In some implementations, the client-defined combination ofbehaviors includes at least one predefined component behavior. In someimplementations, the client-defined combination of behaviors includes atleast one component behavior, wherein the instructions cause thecomputer system to receive token-behavior code programmatically definingthe at least one component behavior, In some implementations, theinstructions cause the computer system to verify operability of thetoken-behavior code on the virtual ledger. In some implementations, theinstructions cause the computer system to assess self-consistency of theclient-defined combination of behaviors. In some implementations, thetemplate is a derived template that inherits one or more properties of apreexisting template, wherein one or more behaviors defined by epreexisting template are overridden by the client-defined combination ofbehaviors as defined by the derived template. In some implementations,the instructions cause the computer system to represent theclient-defined combination of behaviors as a text expression. In someimplementations, the instructions cause the computer system to assessself-consistency of the client-defined combination of behaviors, whereinthe self-consistency is assessed by application of a token-behaviorgrammar.

Another aspect of this disclosure is directed to a computer-implementedmethod comprising receiving a token-behavior selection corresponding toa real-world asset to be tracked on a virtual ledger, the token-behaviorselection identifying a client-defined combination of behaviors;constructing a template for registration of a token class on the virtualledger according to a provider-defined architecture of the virtualledger, wherein each new token instantiated from the token classexhibits the client-defined combination of behaviors as determined bythe token-behavior selection; adding the token class to the virtualledger; receiving a token-management request relating to at least onetoken instantiated from the token class; reformulating thetoken-management request according to the provider-defined architectureof the virtual ledger; and submitting the reformulated token-managementrequest to a networkhosting the virtual ledger.

In some implementations, the client-defined combination of behaviorsincludes at least one predefined component behavior. In someimplementations, the client-defined combination of behaviors includes atleast one component behavior, the method further comprising receivingtoken-behavior code programmatically defining the at least one componentbehavior. In some implementations, the method further comprisesverifying operability of the token-behavior code on the virtual ledger.In some implementations, the method further comprises assessingself-consistency of the client-defined combination of behaviors. In someimplementations, the template is a derived template that inherits one ormore properties of a preexisting template, wherein one or more behaviorsdefined by the preexisting template are overridden by the client-definedcombination of behaviors as defined by the derived template.

It will be understood that the configurations and/or approachesdescribed herein are exemplary in nature, and that these specificembodiments or examples are not to be considered in a limiting sense,because numerous variations are possible. The specific routines ormethods described herein may represent one or more of any number ofprocessing strategies. As such, various acts illustrated and/ordescribed may be performed in the sequence illustrated and/or described,in other sequences, in parallel, or omitted. Likewise, the order of theabove-described processes may be changed.

The subject matter of the present disclosure includes all novel andnon-obvious combinations and sub-combinations of the various processes,systems and configurations, and other features, functions, acts, and/orproperties disclosed herein, as well as any and all equivalents thereof.

1. A computer-implemented method comprising: receiving a token-behaviorselection corresponding to a real-world asset to be tracked on ablockchain ledger, the token-behavior selection identifying aclient-defined combination of behaviors; receiving token-behavior codeprogrammatically defining at least one component behavior of theclient-defined combination of behaviors; constructing a template forregistration of a token class on the blockchain ledger according to aprovider-defined architecture of the blockchain ledger, wherein each newtoken instantiated from the token class exhibits the client-definedcombination of behaviors as determined by the token-behavior selection;and adding the token class to the blockchain ledger.
 2. The method ofclaim 1 further comprising verifying operability of the token-behaviorcode on the blockchain ledger.
 3. The method of claim 1 furthercomprising assessing self-consistency of the client-defined combinationof behaviors.
 4. The method of claim 1 wherein the template is a derivedtemplate that inherits one or more properties of a preexisting template,and wherein one or more behaviors defined by the preexisting templateare overridden by the client-defined combination of behaviors as definedby the derived template.
 5. The method of claim 1 wherein theclient-defined combination of behaviors includes at least one predefinedcomponent behavior.
 6. A computer system comprising: a logic system; andoperatively coupled to the logic system, a computer-memory systemholding instructions that, when executed by the logic system, cause thecomputer system to: receive a token-behavior selection corresponding toa real-world asset to be tracked0 on a virtual ledger., the tokenbehavior selection identifying a client-defined combination ofbehaviors; construct a template for registration of a token class on thevirtual ledger according to a provider-defined architecture of thevirtual ledger, wherein each new token instantiated from the token classexhibits the client-defined combination of behaviors as determined bythe token-behavior selection.; and provide access to the template to aclient computer device.
 7. The co of claim 6 wherein the virtual ledgerincludes a blockchain ledger.
 8. The computer system of claim 6 whereinthe client-defined combination of behaviors includes at least onepredefined component behavior.
 9. The computer system of claim 6 whereinthe client-defined combination of behaviors includes at least onecomponent behavior, and wherein the instructions cause the computersystem to receive token-behavior code programmatically defining the atleast one component behavior.
 10. The computer system of claim 9 whereinthe instructions cause the computer system to verify operability of thetoken-behavior code on the virtual ledger.
 11. The computer system ofclaim 6 wherein the instructions cause the computer system to assessself-consistency of the client-defined combination of behaviors.
 12. Thecomputer system of claim 6 wherein the template is a derived templatethat inherits one or more properties of a preexisting template, andwherein one or more behaviors defined by the preexisting template areoverridden by the client-defined combination of behaviors as defined bythe derived template.
 13. The computer system of claim 6 wherein theinstructions cause the computer system to represent the client-definedcombination of behaviors as a text expression.
 14. The computer systemof claim 13 wherein the instructions cause the computer system to assessself-consistency of the client-defined combination of behaviors, andwherein the self-consistency is assessed by application of atoken-behavior grammar.
 15. A computer-implemented method comprising:receiving a token-behavior selection corresponding to a real-world assetto be tracked on a virtual ledger, the token-behavior selectionidentifying a client-defined combination of behaviors; constructing atemplate for registration of a token class on the virtual ledgeraccording to a provider-defined architecture of the virtual ledger,wherein each new token instantiated from the token class exhibits theclient-defined combination of behaviors as determined by thetoken-behavior selection; adding the token class to the virtual ledger;receiving a token-management request relating to at least one tokeninstantiated from the token class; reformulating the token-managementrequest according to the provider-defined architecture of the virtualledger; and submitting the reformulated token-management request o anetwork hosting the virtual ledger.
 16. The method of claim 15 whereinthe client-defined combination of behaviors includes at least onepredefined component behavior.
 17. The method of claim 15 wherein theclient-defined combination of behaviors includes at least one componentbehavior, the method further comprising receiving token-behavior codeprogrammatically defining the at least one component behavior.
 18. Themethod of claim 17 further comprising verifying operability of thetoken-behavior code on the virtual ledger.
 19. The method of claim 18further comprising assessing self-consistency of the client-definedcombination of behaviors.
 20. The method of claim 17 wherein thetemplate is a derived template that inherits one or more properties of apreexisting template, and wherein one or more behaviors defined by thepreexisting template are overridden by the client-defined combination ofbehaviors as defined by the derived template.